Demo

Jenkins

demos.haus

It would be a nice to have to be able to have hover text on the disabled input for connect when NAT is enabled, however it does not take an onhover param. Any tips here, @edlerd ?

Also, @piperdeck , thanks in advance for the design review. The current code structure doesn't quite allow for the nicer look of having the input labels to the left of the input field. Even with the stacked attribute on the inputs, they end up looking indented and out of place. I tried exploring a few different ways to achieve your design but what not quite able. Perhaps some further light might be able to be shed on this by a reviewer...

I'm getting some strange behaviour where my mouse pointer is showing the pointing finger when I hover over the field label. This is different from when I hover over any other field label that isn't on this page:

Also noticing that the address fields don't adapt to when Unix is selected as the connection type. Because unix sockets aren't like IP addresses, and they're of the form /path/to/socket.sock, the fields should change when I change the port type:

I'm not sure if this is what David is talking about in his previous comment, but when the user set NAT mode to true, the connection types for listen and connect should always be the same. Also, neither one can be Unix if NAT mode is enabled. But that behaviour isn't showing up at the moment:

These fields should probably be filled by their default values, rather than by "Select option":

I'm also noticing that the mode and UID/GID fields are missing when Unix is selected for the listen address. Did we opt not to include those?

@piperdeck , thanks for your review. A few comments :)

• I have since been able to replicate your design! Apologies for the delay and thanks for creating it.
• Enabling NAT now disables the type field in Connect and the Connect Type reflects the Listen type when it is changed.
• Currently working on automatically matching the Connect Type to the Listen Type if/when they are indifferent before NAT is enabled.

1. I was not aware of the Unix layout changing being a task or issue. I'll ask for more information on this.
2. Regarding the mouse pointer, I find that the mous pointer becomes a pointer finger when hovering over the labels of any config in the GPU, Proxy, Other and Network tabs. I believe it is thus inkeeping with the existing style. I can look into this further if you would like/need?
3. Regarding the default values, I was advised that Selecting an option would be a good way to move forward to avoid ... Missing some of the inputs? So users have to manually select each of their options.
4. Are Mode and GID/UID inputs specific to Unix types? @edlerd , please could you advise on how to proceed here, as I believe we were removing the mode section but I'm not sure about the GID/UID.

Note to self: If NAT is enabled, neither Listen nor Connect can be UNIX.

• Regarding the mouse pointer, I find that the mous pointer becomes a pointer finger when hovering over the labels of any config in the GPU, Proxy, Other and Network tabs. I believe it is thus inkeeping with the existing style. I can look into this further if you would like/need?

I think this is default for HTML labels and should be all right from my point of view.

• Regarding the default values, I was advised that Selecting an option would be a good way to move forward to avoid ... Missing some of the inputs? So users have to manually select each of their options.

I asked to remove the defaults earlier, because otherwise there is no way for a user to create a proxy device without those values being set. Now I am not so sure. Maybe we should preselect the default values that LXD will enforce?

Another thought: Should we remove the HAProxy protocol selector? I am not so sure how relevant it is, have a suspicion it is kind of a special use case thing we might want to hide from the average UI user.

• Are Mode and GID/UID inputs specific to Unix types? @edlerd , please could you advise on how to proceed here, as I believe we were removing the mode section but I'm not sure about the GID/UID.

I think Mode, GID and UID are for very special use cases, maybe we can ignore them in the UI to keep the form simple?

• Regarding the mouse pointer, I find that the mous pointer becomes a pointer finger when hovering over the labels of any config in the GPU, Proxy, Other and Network tabs. I believe it is thus inkeeping with the existing style. I can look into this further if you would like/need?

I think this is default for HTML labels and should be all right from my point of view.

• Regarding the default values, I was advised that Selecting an option would be a good way to move forward to avoid ... Missing some of the inputs? So users have to manually select each of their options.

I asked to remove the defaults earlier, because otherwise there is no way for a user to create a proxy device without those values being set. Now I am not so sure. Maybe we should preselect the default values that LXD will enforce?

Another thought: Should we remove the HAProxy protocol selector? I am not so sure how relevant it is, have a suspicion it is kind of a special use case thing we might want to hide from the average UI user.

• Are Mode and GID/UID inputs specific to Unix types? @edlerd , please could you advise on how to proceed here, as I believe we were removing the mode section but I'm not sure about the GID/UID.

I think Mode, GID and UID are for very special use cases, maybe we can ignore them in the UI to keep the form simple?

Noted. @piperdeck , how far do you agree with this?
I am happy to move forward in either case.

Regarding the default values, I was advised that Selecting an option would be a good way to move forward to avoid ... Missing some of the inputs? So users have to manually select each of their options.

I asked to remove the defaults earlier, because otherwise there is no way for a user to create a proxy device without those values being set. Now I am not so sure. Maybe we should preselect the default values that LXD will enforce?

My concern is that I want the user to actually know what the value of the default is. Like in the Bind field, with it set to Choose option, there's no intuitive way to know whether this configuration is going to bind to the host or the instance (for example). This is a tricky question. Am I understanding correctly that on the back end, there's a difference between implicitly keeping the default value and explicitly setting the default value?

In that case, is there any reason for use to ever leave that field implicit, rather than declaring it explicitly? I would lean toward that solution personally.

Regarding the mouse pointer, I find that the mous pointer becomes a pointer finger when hovering over the labels of any config in the GPU, Proxy, Other and Network tabs. I believe it is thus inkeeping with the existing style. I can look into this further if you would like/need?

I think this is default for HTML labels and should be all right from my point of view.

I'm ok with the behaviour in theory, it's just that it's not consistent with field labels on our other pages. It's setting off alarm bells for me that there's something different in the implementation that might need to be brought back in line. But even if all the code is ok, I think that this kind of consistency is important for maintaining a general feeling of quality

Regarding HAproxy and GUI/ID options, if they're really advanced options, I'm ok with reserving them for the YAML editor since we have it. We might have actually discussed this before, apologies if it's just my bad for forgetting :P

@edlerd I'll remove the HAProxy input for now (and add this to the Spec), but isn't the solution just as simple as checking that NAT is disabled? Or is the problem moreso telling the User at the right time that certain configs aren't allowed?

isn't the solution just as simple as checking that NAT is disabled? Or is the problem moreso telling the User at the right time that certain configs aren't allowed?

There are many special cases here and handling them well is a can of worms. Probably best to avoid this complexity. Some examples:

1. user already selected listen mode unix and entered a socket. Then decides to switch on nat mode and then enables haproxy
2. user selected nat mode and haproxy protocol, now we need to only allow selecting type tcp, no udp or unix socket. This will be very confusing.
3. etc.